Event Storming Part 1 - 簡介與事前準備

隨著現代軟體的服務越來越複雜，開發人員要面對的商業邏輯的複雜度也跟著起飛。商業團隊的需求時常在變，而當開發人員只能照著模糊又瑣碎的需求書摸石頭過河時，專案失敗的風險跟著提升、團隊間的隔閡也跟著擴大。

事實上，一項軟體產品所需要的領域知識往往是跨團隊的，沒有任何單一團隊可以掌握它的全貌。但要如何媒合不同背景知識的人做有效溝通非常的困難。幸好在 2013 年，一位義大利人 Alberto Brandolini 發明了 Event Storming 工作坊提供了一個不錯的解決方案。

本主題分為四篇，分為 「事前準備」、「展開風暴」、**「進入軟體設計」**以及 「可以做得更好的部分」，即使沒有學過 DDD 也可以上手。同時先聲明，使用事件風暴不代表一定要採用 DDD，只要你有意想促進團隊的溝通與領域知識的理解， Event Storming 永遠都是你的選項之一！

本篇涵蓋內容：

• Event Storming 概覽
• Event Storming 應用場景
• Event Storming 事前準備

註：在本系列中，我會用英文如 Event、Command 來指便利貼，而如果只是單純敘述事情我會用中文如事件來描述。

Event Storming 概覽

Event Storming 是一個透過高度互動的方式，將企業或系統的商業流程視覺化，最終協助建立軟體模型的工作坊。簡單來說就是探索功能、找出盲點、建立共識。

跑完後，與會者們都將會獲得：

• 對於商業流程的共同理解，包含名詞使用、責任範圍、使用者體驗等。
• 一份整體流程的概覽圖 (Big Picture)，事後也可以數位化製成文件。
• 可以找出商業流程中的核心價值、風險與機會。
• 一個導入 DDD 的好起點。

整個過程中會用便利貼來視覺化流程，不會有艱深的技術詞彙或商業報表，只會有團隊學習與多元觀點的對話。實際跑起來會像是這樣：

適合的對象

如果你的工作流程出現以下症狀，請儘早服用 Event Storming：

• 規格書的知識瑣碎、難以理解、沒有明確架構。
• 討論時常陷入細節的爭論，或是過多的技術詞彙讓主題失焦。
• 開發到一半還在理解功能在幹嘛。
• 等到上線了才發現一堆 Bug。

Event Storming 應用場景

使用的場景點從巨觀到微觀：

1. Big Picture 綜觀全局 ── 釐清混亂的商業流程，凸顯出合作關係、邊界、責任歸屬與不同利益相關者的觀點。
   • 邀請任何有興趣的人、不用限制討論範圍
   • 找出瓶頸、核心價值甚至是新的解決方案
   • 主要以 Event、System、Question 為主。
   • 適合新創或小團隊(人少、技術債少)
2. Process Modelling 流程展示 ── 討論特定功能流程，以確保沒有理解錯誤。
   • 有明確範圍，所以路徑越完整越好。
   • 在細節中找出流程的 Bug，並且每個 Bug 都需要被處理。
   • 再加上 Event、Actor、Command、System、Policy、Read Model。
3. Software Design 軟體設計 ── 利用前面的產出進一步設計軟體
   • 加入 Aggregate、Bounded Context 建立模型邊界。
   • 對於用詞更加精準

你可以照順序從 1 至 3，或是混合使用皆可。

(source: https://www.slideshare.net/ziobrando/50000-orange-stickies-later)

此外， Event Storming 也可以讓新進員工快速上手領域知識。想知道更仔細的，可以看這部 GOTO 2018 • 50.000 Orange Stickies Later • Alberto Brandolini。

事前準備

一場好的 Event Storming，人事時地物缺一不可。

場地設置

• 找到一面限制最少的表面來進行活動。
  不管是牆面、窗邊甚至用多面移動白板組成都可以。你無法預測最後的產出有多少，所以盡你所能，不要因為空間而限制活動的品質。
• 在表面上貼上大型畫紙捲方便收納產出以及進行另一場 Event Storming。
• 以最大化活動空間。將現場的雜物移開，不過可以留下一張小桌子放道具。
• 一定要將椅子移走。經驗中，只要有人坐下，就會開始沈默，最後自我放逐。
• (建議)一面白板或海報寫上名詞定義清單。這場會議中的對話都要遵照清單上的用詞。
• 提供幾張有圖示標明 (Legend) 的海報紙。可以參考以下圖示：

便利貼種類與互動模式：

(source: https://leanpub.com/introducing_eventstorming)

每種便利貼的詳細用法：

(source: https://medium.com/@springdo/a-facilitators-recipe-for-event-storming-941dcb38db0d)

當你準備好場地，大概就會長這樣子。

(source: https://leanpub.com/introducing_eventstorming)

邀請對的人

這是最重要的元素。一場 Event Storming 會需要以下角色：

• 主持人 Facilitator:
  建議一定要有一名參與者負責主持會議進行、推動議程討論。要嚴格注意時間與流程。最好不要跟 Domain Expert 重複。
• 領域專家(們) Domain expert(s):
  專案的主要推動者，或是擁有足夠領域知識的人，建議最好有一定的決定權，在陷入泥沼時才可以做出決定。如果是新創領域，可以事先做好使用者訪談或是找使用者來參加。可以不只一名。
• 其他利益相關者 Other Stackholder:
  可能是參與專案的工程師、設計師，也可能任何能提供專業意見的人士如業務、商業分析師甚至是主管。

通常一場 Event Storming 有 6-8 人就可以進行一場精彩的混戰交流，至於超過 10 人以個人經驗來說，除非主持人經驗豐富，否則場面就會開始混亂起來。

火力展示你的道具

你需要「非常多」的便利貼。千萬不要因為省錢就少買某個顏色，因為每個顏色都有各自的意義，無法互相替代。你會需要以下顏色的便利貼：

• 橘色（正方形 76*76）：Event 事件
• 藍色（正方形）：Command 命令
• 紫色（長方形）: Policy/Process 商業政策/流程
• 黃色（小張長方形）:Actor 角色
• 黃色（長方形）:Aggregate 聚合
• 粉紅色（長方形）：System 外部系統
• 紅色（正方形）:Hotspot 熱點
• 紅色（小張長方形）:Problem 疑問
• 綠色（小張長方形）:Opportunity 機會
• 綠色（正方形）：Read Model 資料讀取模型
• 白色（大張正方形）：Uset Interface 使用者介面

以上顏色皆可以自行調整，不過 Event 還是熟悉的橘色最對味。接著還有其他道具：

• 簽字筆。每個人至少一支。
• 一隻粗一點的奇異筆。
• (推薦)計時器。可以幫助時間控管。
• (選用)投影設備。方便讓領域專家解說需求。

可以參考這張購物清單

滿滿的能量

Event Storming 超級耗費心力，可以喝杯咖啡後再上路。或是在周圍放些小點心供與會者取用。

線上替代方案

如果你想要愛地球減少浪費，或是時間跟人都擠不出來，可以考慮使用線上版工具 Miro。

(Miro 使用示意圖)

Summary

Event Storming 是一個知識交流、打破穀倉效應 (silo effect) 的絕佳場所。同時對於團隊來說是一個非常好的「階段式學習」過程。過程中不但可以提早發現盲點，也能讓未來開發專注在核心功能上。最重要的事，他可以讓原本各自為政的團隊有機會聚在一起達成共識。從商業層面來看， Event Storming 讓我們綜覽全局來辨識出問題的癥結點，並專注在核心競爭力上；從開發層面來看，Event Storming 提供了一個有效的建構軟體方向，讓開發更有自信且減少貧血模型的使用。甚至可以將成果導入 DDD Strategic Design (DDD 剛出來時，就是因為溝通難度太高讓很多人放棄 Strategic Design 結果讓導入成效事倍功半)。

除此之外，使用 Event Storming 除了提升開會的效率，更重要的是帶來個人的成長。一名開發者的價值並不僅僅在於會用多少技術，也與工作領域的熟悉程度有高度相關。當你對於某項產業的理解越深刻，加上技術能力，你就越難被取代。甚至，你可以從技術人員升為顧問，一同參與重要的商業決策。

Resources

以下都是非常好的學習資源，每篇都值得一讀：

• humank/EventStormingWorkShop

• A facilitators recipe for Event Storming

• 50.000 orange stickies later

• 事件風暴-領域建模

• Modelling Reactive Systems with Event Storming and Domain-Driven Design

• Event Storming For Rapid Domain Learning

• cheatsheet

• A step by step guide to Event Storming – our experience

• YOW! West 2016 Paul Rayner - EventStorming #YOWWest

• Detailed Agenda of a DDD Big Picture Event Storming - Part 1

• Detailed Agenda of a DDD Big Picture Event Storming - Part 2

• Detailed Agenda of a DDD Big Picture Event Storming - Part 3

• cover photo

• DDD: Recognising relationships between bounded contexts

• Strategic Domain Driven Design with Context Mapping

• https://www.slideshare.net/YiChengKuo1/implementing-domaindriven-design-study-group-chapter-3-context-maps